home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19941221-19950208
/
000040_news@columbia.edu_Wed Dec 28 21:00:14 1994.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
2KB
Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA21514
(5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Wed, 28 Dec 1994 16:00:17 -0500
Received: by apakabar.cc.columbia.edu id AA02154
(5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Wed, 28 Dec 1994 16:00:15 -0500
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Binary Uploads going through a comm server
Date: 28 Dec 1994 21:00:14 GMT
Organization: Columbia University
Lines: 28
Message-Id: <3dsjku$238@apakabar.cc.columbia.edu>
References: <3dsife$ekq@dgis.dtic.dla.mil>
Nntp-Posting-Host: watsun.cc.columbia.edu
Apparently-To: kermit.misc@watsun.cc.columbia.edu
In article <3dsife$ekq@dgis.dtic.dla.mil>, <Martin B. Isaksen> wrote:
>I cannot upload binary files through a Penril communications server using 4E
>C-Kermit. The same file can be uploaded when I use a port on the back of my
>SUN (SUN OS 4.1.3) machine directly -- but when I try to go through the comm
>server it does not work. Does anybody have any clues???? (file type is set
>for binary).
>
It probably does not affect this problem, but the current version of C-Kermit
is 5A(190).
The most common reason for failed uploads is inadequate buffer capacity on the
receiving end, probably the Penril device in this case, coupled with the lack
of an effective means of flow control.
Solution: reconfigure the communications server to have big buffers in the
receiving direction as well as in the sending direction, and enable the
most effective possible means of flow control (preferably RTS/CTS) between
this device and the one it is most immediately connected to (presumably a
modem). Same deal on the calling end.
If the Penril and/or modem are unfixable, then use end-to-end Xon/Xoff flow
control, which is less satisfactory as it is subject to latency and loss,
and reduce Kermit's packet size until transfers start to work.
If that's not it, then maybe we have a transparency problem, but let's try
this approach first.
- Frank